Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/More Source/C⁄C++/Xconq 7.0d37/doc/play.texi

Texinfo Document | 1995-05-04 | 59KB | 1,228 lines

@node Playing Xconq, Game Design, Acknowledgments, Top
@chapter Playing Xconq
This chapter is about how to play @i{Xconq}.
Although @i{Xconq} supports a wide variety of games,
and runs on many different computer systems,
they all have much in common,
and it is these common features that will be described here.
This chapter, along with the document for your system
and the document for the game you're playing,
should provide all the information you need to play
and enjoy @i{Xconq}.
The term @dfn{interface} refers to the particular graphical user
interface in use.  Examples include X11, curses, and Macintosh.
Interfaces can vary radically from each other, since each is designed
to be best suited for its environment.
In practice though, interfaces will tend to share the same commands,
so that you don't learn to learn a whole new set when
switching computers.
When reading this chapter, you should be aware that the term
@dfn{game} is more precisely @dfn{game design}, since it is
the set of rules and definitions of the game you want
to play.  Since @i{Xconq} allows for many different kinds of
games designs, much of the information in this chapter will
be irrelevant to a particular game.  This will be indicated
by phrases like ``some games'' or by saying that a game ``may''
implement some concept or behavior.  You should learn what
the game you're playing actually does in these cases.
The names of the variables or tables to look at will often
be mentioned in @code{computer type}.
@node Setting Up, Starting Play, Xconq Games, Playing Xconq
@section Setting Up A Game
To get started with @i{Xconq},
you have to select which game you want to play.
The possibilities may be
presented to you, or you may have to look in some sort of library
to see what's available and then supply that name on a command line.
If you don't do anything, then you will get a default game.
Some games require no additional setup;
once loaded, you're ready to go.
Others will require additional decisions,
such as the size and shape of the playing area,
whether exploration will be necessary, or
whether the game is realtime.
These will all be called @dfn{variants}.
The exact set of variants is determined by the game design,
and the interface will (usually) tell you about them.
In addition, most games also give you a choice of
which player is to play which side in a game,
as well how many players can join in.
There are two kinds of players: humans, who have displays,
and @dfn{artificial intelligence}s or @dfn{AI}s for short, which are
run by the computer.  Some versions of @i{Xconq} may include
more than one kind of AI; each type has a distinct name.
The AI named @code{mplayer} is always available.
An example might be a simulation of Europe @i{ca} 1900,
named @code{"la-belle-epoque"}, in which the
sides might be ``England'', ``France'', ``Germany'',
and ``Austria-Hungary'', and
the players might be Joe on a Sun-4, Natalie on a Mac, and
two of the @code{mplayer} AIs.  You can set
Natalie to play England, Joe to play Germany, and the two AIs
to play France and Austria-Hungary.
Some game designs provide a way to even things up if the players
are of vastly differing abilities.
In these designs, each player has an @dfn{advantage} that affects
how much he or she gets to start with.
Weaker players should get a
higher advantage, so for instance a game with two players, of advantages
1 and 4, might give the advantage=4 player 8 cities while the advantage=1
player gets only 2.
This affects setup only; during the game all players are equal.
The variability of advantage also depends on the game; some may
allows differences of 10 to 1 or more, while others, especially
historically accurate scenarios, will have a fixed advantage that
the designer has set for each side.
Once a trial player setup has been made,
@i{Xconq} runs ``synthesis methods''.
These methods are specified by the game design,
and randomly generate anything that was not explicitly spelled out;
for instance, the initial location of countries, terrain features,
and so forth.
As a player, you don't have to concern yourself about synthesis
methods, but you should be aware that
you may sometimes run into situations were a synthesis method simply cannot
cope, and your game setup will fail.  A common case is where you
ask for many players to be set up in a small world, and the
set of constraints is too ``tight'' for an initial setup to
succeed.  In such cases, you just have to try different setups
and maybe complain to the game designer.
Synthesis methods may also take a long time to run; for large worlds
and lots of players, be prepared to wait.
When initialization and setup succeeds, @i{Xconq} will try to open up
displays for every player that wanted one.
Exactly how this happens depends on the interface and networking
capabilities of the version of @i{Xconq} you're using.
Once this is done, @i{Xconq} will start the game for real.
You may also get a warning that ``images were not found''.
This happens when the game design specifies the use of
particular icons or patterns (collectively call @dfn{images}
here), but they cannot be found
anywhere by @i{Xconq}.  This is not fatal, because @i{Xconq}
will use generic default images instead, but the display may
be hard to understand.  There are several possible reasons
for images not to be found: 1) the game designer might have
specified the use of particular images, but never defined them,
2) the library of images was not updated to include the needed
images, or 3) the image library is not located where Xconq is
looking.
@c any other setup warnings to document?
@node Starting Play, Worlds, Setting Up, Playing Xconq
@section Starting Play
What you'll first see depends entirely on the interface you're using.
Typically there will be a map and a list of sides, possibly other
displays as well.
Help is available in the ``usual'' ways,
and the interface is robust, so you can always just try
to find your way around by experimentation.
(This is best done by yourself, rather than in a game with a lot
of other people.)
The game proceeds as a sequence of @dfn{turns}.
During each turn, you and the other players get to move
your @dfn{units}, which can be anything from cities to submarines
to insects, depending on the game.
In addition, there may be @dfn{backdrop activities},
such as changing seasons and weather, that go on all by themselves.
These typically happen at the beginning or end of a turn,
not while players are moving their units.
Your exact goal in the game depends on the @dfn{scorekeepers}.
Most games have at least one, some have several, and some have none.
There are many kinds of scorekeepers, so be sure you know and
understand what they are before getting too far into a game!
If there are no scorekeepers at all, you can do whatever you like;
any AIs playing in such a game will behave quite randomly.
A game may last anywhere from a few turns to many hundreds.
Again, this may be limited by the game design,
or perhaps by the nature of the game.  For instance, a game
of oil empires might be forced to end when the world's oil
supplies are exhausted...
@node Worlds, Units, Starting Play, Playing Xconq
@section Worlds and Areas
@quotation
Gallia est omnis divisa in partes tres [All Gaul is divided into three
parts] -- JULIUS CAESAR
@end quotation
The @i{Xconq} ``world'' is always a sphere.  However, you only play
on a piece of its surface, which is called an @dfn{area}.
Currently, there can only be one world and one area in a game;
this may change in a future version of @i{Xconq}.
An area is divided into a grid pattern of @dfn{cells}.
Although squares with four or eight neighbors could be used
(and were, in the very first version of @i{Xconq}),
currently only a hexagon grid is available.
Each cell is therefore adjacent to six others,
in the directions NW, NE, W, E, SW, and SE.
Areas have a @dfn{width} and @dfn{height} that are the number
of cells across and up/down.
Although you can ask for areas down to 10x10 or less,
or up to 1000x1000 or even more, the ideal default is typically
around 60x30.  Larger areas consume vast quantities of memory,
plus they're slow and unwieldy to play on.
If the area's width matches the circumference of the world,
it is a cylinder in shape.
The cylinder can be circumnavigated in an east-west direction.
This is what an 8x6 cylinder area might look like
(periods are sea, @code{+} and @code{^} are land,
@code{#} indicates edge cells):
@example
# # # # # # # #
 . . + + . . . .
. . . + ^ . . .
 . . . . . . . .
. . . . ^ . . .
 # # # # # # # #
@end example
Areas whose width is less than the world's circumference
have a hexagonal shape.
This is an 8x7 hexagon:
@example
   # # # # #
  # . + + . #
 # . . + ^ . #
# . . + ^ . . #
 # . . . . . #
  # . . ^ . #
   # # # # #
@end example
The top and bottom rows of the cylinder shape,
and all the sides of the hexagon shape, although
they are displayed, may not be entered (except when leaving the world
entirely, which some games allow).
These cells are called @dfn{edge} cells.
The types of terrain you'll find in the world depends on the game design;
typically there will be sea, land, mountains, swamp, and so forth,
but more exotic games have been known to
feature junkheaps, lava, and black holes as ``terrain''.
Terrain can cover an entire cell, be linear features
passing through or between cells, or be a coating
overlaying other terrain.
@dfn{Cell terrain} covers the entire cell uniformly,
right out to its edges.
A @dfn{border} is the boundary between two adjacent cells;
it has a distinct terrain type, such as ``river'' or ``beach''.
A @dfn{connection} is a narrow ribbon of terrain that reaches
from the middle of one cell to the middle of an adjacent cell.
Like borders, connections are distinct types, for instance ``road'',
``railway'', or ``canal''.
Connections take precedence over borders and underlying cell terrain;
in other words, if cell or border terrain is impassable, but there is
a passable connection type, then the connection allows passage.
Thus a connection can be usable as a bridge.
You may also find more than one type of connection or border,
between two cells, such as both a road and a rail line.
A @dfn{coating} is like snow; it is a type that co-exists with
cell terrain.  Coatings can change from turn to turn, varying
in depth.
Note that any single terrain type can only play one of these roles.
This means you will never have river terrain that is both border
and connection, nor will snow be both a coating and a cell type.
In some games, each cell has an @dfn{elevation}, which is basically
elevation above sea level, but could be any range of values, as set
by the game design.
The game design also defines the effect of elevation on movement,
visibility, weather, and so forth.
A world can have named @dfn{geographical features} or just @dfn{features},
such as a bay, mountain, desert, or valley.
Geographical features never have any direct effect on your game,
but some interfaces may label features when drawing a map,
or use them to help describe locations verbally,
in phrases like @code{"1 hex NW of Broken Hill"}.
A world can have @dfn{people} living in some or all of its cells.
People belonging to a side report everything
they see in their cell to their side.
Some types of units will change the people's side to the
unit's, if that unit is of the proper type,
such as an occupying army.
@node Units, Materials, Worlds, Playing Xconq
@section Units
@dfn{Units} can be almost anything:
adventurers, armies, balloons, bicycles, dragons, triremes, spiders,
battleships, bridges, headquarters, cities.
Units move around, manufacture things,
fight with other units, and possibly die.
They are the playing pieces of @i{Xconq}.
Units have a location, either in out in the open terrain of
a cell, or inside some other unit.
In games that define connections, a unit may be
on the connection rather
than on the predominant terrain of the cell.
(Think of a truck on a bridge.)
There may be more than one unit in the open in a given cell,
up to a game-defined limit.
The collection of units sharing a cell is called a @dfn{stack}.
A unit inside another unit will be called
an @dfn{occupant} in a @dfn{transport},
even if the ``transport'' is a type that can never move.
A unit's location may also include an @dfn{altitude},
expressed as its distance above the surface of the cell it is in.
A unit either belongs to a side, or else it is considered @dfn{independent}.
Independent units do not do very much.
In more complex games, the unit's side merely represents the
current ownership, and the unit may have a range of feelings
towards each side, including its current one.
In those games, it is possible for one of your units to be a traitor!
Units can have a name, full name, a title, and a number,
as appropriate to the situation.
The name is an ordinary name like ``Joe Schmoe'' or ``Cincinnati'',
while the full name might be something like ``Joseph P. Schmoe''.
The title is a form of address such as ``Lord''.
The unit number, if used, is an ordinal that is maintained
for each side and each unit type,
so you can have both a ``1st national bank'' and
a ``45th infantry division'' on your side.
Names and numbers are always optional,
and can usually be changed at any time during the game.
Every unit starts out with a
number of @dfn{hit points} or @dfn{hp} representing
how much damage it can sustain before dying.
Certain types of units, such as armies and fleet of ships,
have multiple @dfn{parts}, which means that damage to them
reduces their effective size.
Multi-part units can merge with and detach from each other.
Damaged units may recover their hp on their own, or else
be repairable by explicit action, either by themselves or
by another units (ships in port for example).
In addition to occupants, a unit can also carry @dfn{supplies}
(food, fuel, treasure, etc),
which are type of materials (see the next section).
Supplies are used up by movement, combat, and by just existing, and are
gotten either by producing them or by transferring them from some other unit.
Some games start units out with lots of supplies, while in others
you have to acquire them on your own.
What a unit can do at any one time depends on the @dfn{action points} or
@dfn{acp} available to it.  Each sort of action - movement, construction,
repair, etc - uses up at least one action point, and possibly more.
A unit with an acp of 0 can never do anything on its own,
although other units can still manipulate it.
Also, not every type of unit can do every type of action;
this is also defined by the game design.
Section xxx lists all the types of actions that are
possible in @i{Xconq}.
[explain cxp, when it's implemented]
You can lose a unit in many different ways:
in combat, by running out of essential supplies,
by being captured, by revolt, by garrisoning a captured unit,
by leaving the world, or in accidents.
@node Materials, Sides, Units, Playing Xconq
@section Materials
In @i{Xconq}, @dfn{materials} are basically bulk inanimate stuffs,
like food or fuel.
They are kept in units or in cells,
up to limits defined by the game.
Materials may be provided as part of the initial game setup,
or else produced by units and cells.
They are consumed by construction,
movement, or merely in order to survive.
You can also move materials around from unit to unit.
Some games define laws of supply and demand,
which will move materials for you,
though not necessarily in the directions you would prefer!
In a few games, possession of a material type may figure into your
score (your gold in a medieval game, for instance).
In other games, there are no types of materials at all.
@node Sides, Moving Units, Materials, Playing Xconq
@section Sides
Each player in @i{Xconq} runs a @dfn{side}.
The concept of ``side'' is somewhat abstract in @i{Xconq};
units in a game belong to sides,
but the sides themselves are not attached to any particular unit.
Side often represent countries, but not invariably.
It is important to be clear about sides and players.
A side is a part of the simulated world, while a player
is the actual real-world person or program that is playing the side.
You yourself are always the player, but in one game you may play the
German side, and in another the Klingon side.
During a game, there will always be a player for each side,
and vice versa.  The distinction is most important
during setup, since you can swap players between sides.
Each side can have a name and associated parts of speech,
such as a noun for individuals on the side and an adjective
to describe anything belonging to the side.
[example?]
Sides can also have emblems and colors that are used in displays.
Some game designs preset all this, while others let you
personalize as desired.
See the @i{Xconq} document for your system to learn how to do this.
@subsection Interaction Between Sides
In games with two players, your interaction is usually pretty simple,
i.e. bash on each other.  In games with many players, some human, some
mechanical, it is possible to have a variety of relationships, ranging
from complete trust to complete hatred.
One thing you can do is to make your side be controlled by another side.
This is basically surrendering, because the controlling side can
manipulate any of your units as if they were its own.  The controlling
side also has the option of allowing or forbidding you to move your
own units.  The relationship is strictly one-sided, and only the
controlling side can release the controlled side.  (Note that this
is a way to have several people play on a side; have one player run the
controlling side and
be helped by several other players running controlled sides, usually
with agreed-upon responsibilities.)
A less extreme, but still very close, relationship is trust.  This is
like a close ally - you can enter each other's transports, you share
view data, and so forth.  Trust is a two-way relationship; both you
and the other side each have to declare you want to trust the other.
You can do this at any time.
You can also, unilaterally, withdraw your trust in another side
at any time.
@subsection Agreements
@quotation
Diplomacy is to do and say //
The nastiest thing in the nicest way.
-- ISAAC GOLDBERG (1938)
@end quotation
If you don't want to declare a special relationship with another side,
but still want to make some sort of adhoc arrangement, you can create
an @dfn{agreement}.  An agreement is a sort of generalized treaty;
it consists of a number of @dfn{terms} agreed to by a number of
@dfn{signers}, which are sides.  Agreements may be public or secret,
and you can declare them to be enforced by @i{Xconq} if the terms
are in a form it understands. An agreement that just says
``help each other out'' cannot be evaluated by the computer!
To make an agreement, you tell the interface to create one, fill in its
terms, possibly give it a name, make up a list of proposed signers,
then either propose it directly or else send to @dfn{drafters}, which
are the side you want to help with the composition of the agreement.
The draft also includes the list of sides that will know about the
agreement.
When the agreement is officially proposed, it will be displayed to
all sides that are to sign, and represented as coming from the
sides listed as @dfn{proposers}.
@i{Xconq} will then ask each proposed signer to sign;
if all do so, then the agreement goes into effect immediately.
All sides that are to know about the agreement
will be informed of its terms.
Some interfaces may allow players to copy and modify a proposed and
circulate it along with the original.  The proposing side may also
withdraw a proposal, but cannot modify it without having it signed again
by everybody involved.
Once in effect, an agreement cannot be modified, and it cannot be
removed unless it includes a term that provides for this.
An agreement can have any number of terms.
Each term can have one of several forms:
A text string.  This is not interpreted in any way
and could be a comment, preamble, or whatever.
A true/false expression.  This must always be true for the agreement
to be valid.
A statement of an action.  This action will be performed at the instant
that the agreement goes into effect.
An if-then statement.  If the condition is true
while the agreement is in effect, then the action will be performed.
[need some examples]
Note that the drafter/proposer/signer distinction has many uses;
for instance, you can draft an agreement to be proposed by a coalition
of sides, but the proposed signers are neutral sides that you want
to keep quiet.
@subsection Trade
You can specify the nature of the trading relationship with other sides.
The basic theory is that traders are businessfolk and don't care much about
politics; they will do business with anybody.
However, a player can define relationships with other sides via tariffs.
A tariff is a per-side per-material percentage
that will be taken from any transfer from/to units on one side to
units on another side.
You can define both import and export tariffs.
A tariff of zero means free trade,
and negative tariffs are allowed; in such cases your stock of
material is used to add to the transfer.
@subsection Tech Levels
In some game designs, technology and research are important.
These games give each side a set of @dfn{tech levels}
(or just @dfn{tech} for short), one for each type of unit.
The tech level represents the technological knowledge needed to
see, operate and build a type of unit.
Tech levels never decrease (they may in real life, but only over
very long time intervals),
and they can be increased by research and espionage.
There are several tech thresholds for a unit.
First there is @code{tech-to-see}, below which you will not even
be aware of the existence of a unit (consider barbarians unable to see
spy satellites passing overhead).  Then there is @code{tech-to-use},
which you must have in order to make the unit do any actions.
The @code{tech-to-understand} and @code{tech-on-acquisition} are
points at which your side can increase its tech level just by owning
a unit, and finally the @code{tech-to-build} is what you must
have to create new units of the given type.
See below to find out how you can do research and
espionage to increase your tech level.
@subsection Side Classes
In some games, several sides may be very similar, while being very
different from other sides in the same game.
These similar sides can be given the same @dfn{side class}.
Units may then be restricted to be usable only by the sides in
a particular class.  (Note that this is different from tech level,
which allows units to be used by any side that has managed to acquire
a sufficient tech level.)
@subsection Self-Units
A @dfn{self-unit} is one that represents your whole side in some way.
For instance, in a dungeon exploration game, your ``side'' might consist
of an adventurer (you), your possessions, your followers, and perhaps more.
In such a case, if the adventurer dies or is captured, then the game
should be over, at least for you.
Usually the self-unit will be set up by the game design,
and all you have to do is to be aware that losing the self-unit
ends your participation instantly.  Some games might have
``self-unit resurrection'' which just means that if another
unit is available when the self-unit dies, then that another
unit becomes your new self-unit.  This is like where admirals
would leave their sinking flagship and board another ship,
thus ``transferring the flag''.  (Admirals presumably being
more valuable than captains, who're supposed go down with
their ships!)  Some games may also allow you to change self-units
manually.
@node Moving Units, Automation, Sides, Playing Xconq
@section Moving the Units
Once the first turn begins,
you can begin looking at the display and moving your units.
Depending on the game design and startup options, you may or may not
be moving simultaneously with the other players.
If not, then the players move one at a time, in the order that their
sides are listed in any display.
Usually, you can choose freely which units to move next;
you can move one a bit, switch to another, move it, then
come back to the first one later, and so forth.
Some game designs may require that you move units in a specific
order; perhaps all your aircraft must finish all their movement
before any ships can move.
@subsection Turn Setup
First, @i{Xconq} computes the number of action points
available to each unit.
Each unit gets an increment of action points equal to its
@code{acp-per-turn}.  Actions during a turn reduce this down;
when it reaches a value less than the cost of any action,
the unit cannot do anything more until the next turn.
The range of action points for a unit is
normally 0 up to the value of @code{acp-per-turn},
but the parameters @code{acp-min} and @code{acp-max}
may allow for an extended range.
You use this range by allowing a unit to accumulate extra action points
by doing nothing for several turns,
or to recover from an activity that used
many action points all at once.
Think of this as a sort of temporary action ``debt''.
Units in debt at the beginning of a turn cannot act
during that turn.
@subsection Types of Actions
Actions are the most basic kinds of things your units can do.
During play, the interface will usually give you
capabilities that are easy to use, such as the ability
to point at a destination and have the unit figure
out which path to take to get there,
but all such input
eventually breaks down into sequences of actions.
You will therefore find it useful to understand all the types of
actions available.
Movement Group:
@itemize @bullet
@item
@i{Move to} a given location.
The unit being moved may be in a transport or out in the open,
the destination is any location in the open (this will usually,
but not always, be an adjacent cell), and may be at any altitude
allowed for the unit.
@item
@i{Enter} a given transport unit.
The transport need not be on the same
side as the entering unit.
@end itemize
Combat Group:
@itemize @bullet
@item
@i{Attack} a given unit.
A successful attack causes damage and destruction
to the unit being attacked.
@item
@i{Overrun} a given location.
The overrunning unit attempts to
occupy the destination, capturing, ejecting, or eliminating any
unfriendly unit present.
@item
@i{Fire at} a given unit,
possibly using a given material as ammunition.
@item
@i{Fire into} a given location,
possibly using a given material as ammunition.
@item
@i{Capture} a given unit.
@item
@i{Detonate} at a given location.
Detonation causes damage to all unprotected units in the vicinity
of the detonation.
@end itemize
Construction Group:
@itemize @bullet
@item
@i{Research} a given unit type.
This increases the tech level for the type being researched.
@item
@i{Tool up} to build a given unit type.
@item
@i{Create} a unit of the given type.
The unit will usually be incomplete.
@item
@i{Build} a given unit towards completion.
@item
@i{Repair} a given unit, restoring lost hp.
@end itemize
Unit Manipulation Group:
@itemize @bullet
@item
@i{Disband} a given unit, causing it to disappear.
@item
@i{Transfer part} of a unit, either to another given unit,
or creating a new unit.
@item
@i{Change side} of a given unit to a given side.
@item
@i{Change type} of a given unit to a given type.
@end itemize
Material Manipulation Group:
@itemize @bullet
@item
@i{Produce} a given quantity of a given material type.
@item
@i{Transfer} a quantity of a given material type to a given unit.
@end itemize
Terrain Manipulation Group:
@itemize @bullet
@item
@i{Add terrain} of a given type to a given location.
@item
@i{Remove terrain} of a given type from a given location.
@end itemize
Normally, you as the player and the side simply tell units to
perform these actions themselves.
However, some games will allow the unit to cause the action to
done as if another unit were doing the action.
For instance, a transport can pick up or drop off a non-moving unit.
Not all interfaces can be guaranteed to allow the most general forms
of all these actions; you must consult the interface's documentation
to find out which of these actions is available.
@subsection Movement
Movement into a cell is easy to request, but each game will
have many rules constraining possible moves, depending both
on the unit and the terrain it is moving over.
Certain kinds of terrain cost extra points to enter, leave,
or cross.  The destination must almost always be adjacent
to the unit's current location.
The other kind of action is to enter/leave a transport.
The only argument is the unit to enter,
but again the constraints are complicated.
The transport must have sufficient space,
both the entering unit and the transport must have sufficient
mp and acp to complete the move,
and the entering unit must be able to cross the intervening terrain.
The transport may be able to @dfn{ferry} the would-be occupant over
any barriers; possibilities include no ferrying, ferrying only
over the transport's terrain, ferrying over any borders, and ferrying
over all terrain between the would-be occupant and the transport.
In some games, you may be able to make one of your units leave the
world entirely.  Sometimes this will seem like a good idea, perhaps
to keep a trapped unit from falling into enemy hands, or because
you win the game by leaving through a designated place.
To do this, you just direct your unit (which must already be at the edge
of the world) to move into one of the cells along the edge.
If the departure is allowed, then the unit will simply vanish
and be out of the game permanently.
In other games, you may be able to do a @dfn{border slide}.
This is where a unit can jump to a non-adjacent cell if the
two cells have a border whose endpoints touch the starting
and ending cell.  This is typically allowed in games so that
ships can go through narrow straits.
@subsection Combat
@quotation
War is a matter of vital importance to the State; the province of life
or death; the road to survival or ruin.  It is mandatory that it be
thoroughly studied.  -- SUN TZU (ca 400 BC)
@end quotation
There are two basic kinds of combat, each with two versions.
A unit can attack or overrun, meaning that it comes to grips with
an enemy in some way,
or it can fire, meaning that it keeps its position and throws
rocks or whatever at a target.
@dfn{Attack} is directed at a particular unit,
while @dfn{overrun} is a more complex action where the unit
attempts to clear enough units from a given location
so that it can move in.
A unit wishing to attack picks a position
or unit to attack, @i{Xconq} computes the defender's response,
then the outcome is computed.
In many games, that will be the end of a fight.
In others, the units remain engaged in a @dfn{battle},
and they cannot do any other type of action
until they have disengaged completely.
@dfn{Firing} can happen at long ranges, up to the @code{range} of a unit.
It may or may not involve using a specific material as ammunition;
if the game gives you a choice, you will have to choose which,
or else all possible types will be used.
You can @dfn{fire at} a specific unit if you can see it,
otherwise you will have to @dfn{fire into} a cell;
perhaps without knowing whether or not you're actually
hitting anything in it.
Some units are capable of capturing other units, with a probability depending
on the types of both units involved.  If the capture attempt is successful,
the capturer will move into the cell if possible, either as occupant or
transport.  In some games, the capturer may be all or partially disbanded,
to serve as guards.
Capture may also occur as a side effect of a normal attack.
Detonation is a special kind of ``combat'' available to some units.
The action requires a location - either the unit's position or a nearby cell.
Upon detonation, the detonating unit may lose some hp and even die
(changing to its ``wrecked type'', if defined, or else vanishing).
At the same time, it makes one hit on any units within its
radius of effect.  Detonation may also be triggered automatically,
such as by damage to the unit or even by another unit appearing nearby.
@subsection Research
@quotation
Knowledge is power.  -- FRANCIS BACON (1597)
@end quotation
@dfn{Research} increases a side's tech for the unit type
being researched.
Although you can only research a specific type of unit,
some game designs allow for a crossover effect, where increases in the
tech level for one type also increases the level in others.
You can have more than one researcher researching the same type,
and thereby speed up your progress, but some games put a ceiling
(@code{tech-per-turn}) on how much progress you can make in one turn.
@subsection Construction
@quotation
We must be the great arsenal of democracy.
-- FRANKLIN ROOSEVELT (1940)
@end quotation
@dfn{Tooling up} prepares a unit to create or construct the desired type.
As with research, game designs may allow a crossover effect for tooling.
Tooling may also decline gradually over time; this is called
@dfn{tooling attrition}.
Actual construction of a unit happens in two steps; creation and
building towards completion.
Most interfaces will also schedule research and toolup
actions if a unit is told to build something
that needs tech or tooling first.
@dfn{Creation} is the actual step of bringing a new unit into existence.
If the new unit is @i{complete}, then it can be used immediately.
If not (the usual case), then the incomplete unit will exist and belong
to your side, but be unable to do anything at all.
Incomplete transports cannot have any occupants,
unless they are types capable of helping complete the transport.
@dfn{Completion} is achieved by doing build actions on the unit.
Multiple units can all work on completing the same unit,
but they must be sufficiently close, within a range defined by the game
(usually the same or an adjacent cell).
In some games, there
is a level of completion past which the unit will start working
on itself automatically, and eventually become complete without any
further action.
It is @i{usually} the case that the same unit will be able to both
create and complete a unit, but if not, you will have to pay special
attention to your construction plan, since an incomplete unit cannot
act in any way.
Note that multi-part units will be considered ``complete'' when just one
of their parts is completed.  Most interfaces will have the
builder continue growing the just-completed unit as long as it
remains within construction range.
@subsection Repair
@dfn{Repair} restores lost hit points to a unit.
Repairs can be done by the damaged unit itself,
if it is not too badly damaged,
or by another unit that is close enough.
Some games also feature automatic hit point recovery,
so you don't always have to remember to do explicit repair actions.
@subsection Disbanding
@dfn{Disbanding} is a voluntary loss of hp, ultimately resulting
in the disappearance of the unit.
Most games only allow it for a few types of units.
Depending on the game, you may be able to disband the
unit in one turn, or you may need several turns before
the unit actually goes away.
Units with occupants can disband,
but only if the occupants are unaffected by the action.
If the unit would vanish or lose transport capacity,
then the occupants must be disbanded or removed first.
The interface may arrange to do this for you automatically.
You always get back all of the disbanded unit's supplies,
and they will be distributed to other units nearby.
In addition, the disbanded unit itself may become a
source of materials.  A percentage of the total material
will become available after each action, if disbanding
takes several turns to accomplish.
@subsection Transferring Parts
In games where units can vary in size, you can shift one or
more parts of a multi-part unit to another unit,
or else create an entirely new unit.
You would use this action if, for instance, you wanted to detach
a survey party from an exploring expedition, then rejoin later.
@subsection Changing Side
In many games, you can give some of your units to another side.
You may also be able to take them from another side,
if you control that side.
Unlike most actions, you may be able to cause a unit to change
side without actually expending any action points, if the game
definition allows.
@subsection Changing Type
A few games allow you to change the type of a unit.
For instance, you might have this ability in a construction-oriented
game, where you can take a town that has accumulated sufficient
building materials and change it into a city.
Another possibility is that you have increased your technology level
and are now able to transform a low-tech ship into a higher-tech ship.
@subsection Producing Materials
@dfn{Production} is how a unit can produce a quantity of a material.
In many games, units already have a @dfn{base production} that is
the amount of material that they produce automatically each turn.
This will often depend on the terrain, so that explorers in the
forest will always ``produce'' enough water to drink each turn,
but will start to use up their water supply when in the desert.
@subsection Transferring Materials
Often there will be plenty of some type of material in the world,
but the problem is getting it from the units that have a lot,
to the units that need it badly.  The @dfn{transfer} action is
how you move supply from one unit to another.
As with production, many games have some automatic transfers
set up.  For instance, games involving aircraft generally refuel
them automatically whenever the aircraft has landed in a place
with fuel to spare.
@subsection Changing the Terrain
In some games, units can add or remove borders, connections,
or coatings, or may even be able to change the overall type of terrain
in a cell.  The actions are @dfn{add-terrain}, @dfn{remove-terrain},
and @dfn{alter-terrain}, respectively.
The change happens immediately (for the sake of simplicity),
but in practice, you may find that preparing for the change may
take awhile.  For instance, the unit executing the change might
have to accumulate acp or materials required for the change.
@node Automation, Climate Backdrop, Moving Units, Playing Xconq
@section Automation of Units and Sides
Specifying the exact sequence of actions and their operands
for every single unit would be mind-numbingly complex.
It's not very realistic either!
Therefore,
@i{Xconq} includes several levels of automation for human players.
The elements of automation are the @i{task}, the @i{plan}, the
@i{doctrine}, and the @i{strategy}.  These are related to each
other by @i{goals}.
@dfn{Tasks} are single activities of a unit that require one or more
actions to accomplish.  Examples of tasks include moving to a
given position, or waiting 15 turns to be picked up by a transport.
A @dfn{plan} is the unit's object that expresses its decided-upon behavior.
Elements of a plan include a type, goal, and @dfn{task agenda},
as well as more specific slots, such as a pointer to the unit
currently under construction.
All units that can act and that are on a side will have a plan, while independent
units that can act may have one if preset by a scenario.
Plans primarily govern individual behavior, in many cases allowing the unit
to act on its own, without needing any explicit direction from the player.
The @dfn{doctrine} is the set of parameters governing how the side will play
and how its units should work generally.  For instance, per-unit
doctrine specifies the point which a unit low on supply should
start to look for a place to replenish itself.
The @dfn{strategy} and associated subobjects is what an AI
uses to make all the decisions about what to do.  This object is not
directly visible, unless the AI is acting as your assistant
and the interface includes a display of its current strategy.
Of all these types of objects, only the doctrine can be manipulated
directly;  all others are implicitly changed as a result of
player commands, which are different for each interface.
@subsection Doctrine
There is a doctrine for each type of unit on your side.
Several types may share a single doctrine, so changes to
it will affect all types equally.
@itemize @bullet
@item
wait-for-orders
This is true if a unit should wait for explicit orders to be issued.
If false, the unit should make up some sort of default plan and follow it.
@item
resupply-at
@item
rearm-at
@end itemize
[more doctrine info]
@subsection Plans
A unit's plan must be one of the types listed here.
@itemize @bullet
@item
None.  This type of plan does absolutely nothing.
@item
Passive.  Units with a passive plan will execute any tasks they have
been given, but will not add to the task agenda on their own.
[auto-add tasks if required by doctrine?]
@item
Offensive.  Units with an offensive plan will look for favorable
combat opportunities, usually within an area specified as their goal
to hold.
@item
Defensive.
@item
Exploratory.  Exploratory units will seek to collect information about
unknown parts of the world.
@end itemize
@subsection Tasks
Each task in a plan's task agenda must be one of the types listed here.
@itemize @bullet
@item
Do nothing.
@item
Build new units, a given number of a given type.
This task will do research actions if necessary and possible,
and toolup actions if necessary.
Also, if there is an incomplete unit of the given type
nearby, this task will complete it before creating a new unit.
@item
Stand sentry at the present location for a given number of turns.
@item
Move in the given direction up to the given distance.
@item
Move to within a given distance of the given location.
@item
Move towards another given unit.
@item
Patrol an area around one or two given points.
@item
Attempt to hit a unit at a given location.
@item
Attempt to capture a unit at a given location.
@item
Resupply.
@item
Repair.
@end itemize
@subsection Time Limits
One reason to automate your units is that some game
designs define real-time limits on the length of a game.
For instance, the game might be set to end in one hour,
a single turn might be limited to always last at most 2 minutes,
or your side might be limited to 15 minutes of playing time,
in the manner of a chess clock.
If such limits are in effect, your display should be able to show you
how much time you have left at any moment; pay attention!
When you run out of time, you are not automatically taken out of the game,
but you can no longer do anything with your units.  Units that already
have plans will continue to act on them.
The game design may give you a limited number of
``timeouts'' that you can call to stop the clock.
The timeout ends when you order a unit to do something.
[how do players find out about time limits?]
@section Standard Keyboard Commands
These commands should be available in all versions of @i{Xconq}.
Additional commands may be defined for some interfaces;
see the interface's documentation for more details.
@c should add a script to test dir to compare this listing with the
@c commands listed in cmd.def, sort each in consistent order so this
@c doesn't have to be alphabetical order
@code{' '} @code{reserve} put into reserve for this turn
@code{'?'} @code{help} display help info
@code{'!'} @code{detonate} detonate
@code{'.'} @code{recenter} center around the current point
@code{'#'} @code{distance} display distance to selected place
@code{'a'} @code{attack} attack
@code{C-A} @code{auto} toggle AI control of unit
@code{'b'} @code{southwest} move southwest
@code{'B'} @code{southwest mult} move southwest multiple
@code{'C'} @code{clear plan} clear unit plans
@code{C-C} @code{end turn} end activity for this turn
@code{'d'} @code{delay} delay unit action until after others have moved
@code{'D'} @code{disband} disband a unit
@code{'f'} @code{fire} fire
@code{'F'} @code{formation} set formation
@code{'g'} @code{give} give supplies
@code{'G'} @code{give-unit} give unit to side
@code{'h'} @code{west} move west
@code{'H'} @code{west mult} move west multiple
@code{'j'} @code{south} move south
@code{'J'} @code{south mult} move south multiple
@code{'k'} @code{north} move north
@code{'K'} @code{north mult} move north multiple
@code{'l'} @code{east} move east
@code{'L'} @code{east mult} move east multiple
@code{'m'} @code{move to} move to a place
@code{'M'} @code{message} send a message to another side or sides
@code{C-M} @code{end turn} end activity for this turn
@code{'n'} @code{southeast} move southeast
@code{'N'} @code{southeast mult} move southeast multiple
@code{'o'} @code{other} other commands
@code{'p'} @code{produce} set material production
@code{'P'} @code{build} set up construction tasks
@code{'Q'} @code{quit} get out of the game
@code{'r'} @code{return} return to a resupply point
@code{C-R} @code{refresh} refresh display
@code{'s'} @code{sleep} go to sleep
@code{'t'} @code{take} take supplies from unit or terrain
@code{'T'} @code{take unit} take unit from another side
@code{'u'} @code{northeast} move northeast
@code{'U'} @code{northeast mult} move northeast multiple
@code{'w'} @code{wake} wake units up
@code{'W'} @code{wakeall} wake units and all their occupants up
@code{'y'} @code{northwest} move northwest
@code{'Y'} @code{northwest mult} move northwest multiple
@code{'z'} @code{survey} switch between surveying and moving
The following commands are not standardly bound to single keystrokes.
@code{add player} allow another player to come into the game
@code{ai} toggle the AI
@code{copying} display the copying rules
@code{name} set the name of a unit
@code{print} print
@code{version} display the version and copyright
@code{warranty} display the non-warranty
If designing is enabled, then the command
@code{design}
will enable and disable design mode.
See Chapter 3 to find out more about what you can do in this mode.
If debugging hooks are enabled, then the commands
@code{D}
@code{DG}
@code{DM}
will be available.
They cause detailed transcripts of general computation,
graphics, and AI behavior, respectively.
They act as toggles, and are independent of each other,
so you can control what kind of information is output.
The transcript will go to stdout or to a file, depending
on the interface and system.
@node Climate Backdrop, Economy Backdrop, Automation, Playing Xconq
@section Environmental Conditions
Some games include @i{environmental effects},
which includes what we normally think of as weather;
the temperature, clouds, wind, rainfall, snowfall,
and snow cover on the ground.
The temperature falls in a range specified by the game, and may be
computed in different ways depending on the game design,
but typically depends on terrain, latitude,
the severity of the seasons, and elevation.
Temperature may also vary randomly from turn to turn and cell to cell.
The contribution of each of these to the final
temperature is up to the game design, as is the @emph{effect} of
temperature.
For each type of unit, there is both a @dfn{comfort range}
and a @dfn{survival range} of temperatures.
Units within their comfort range are unaffected by the temperature.
Units outside the comfort range, but within the survival range,
may experience reduction in acp and an increase in attrition.
Units outside the survival range die instantly. [add a prob, a al starve?]
A game may include clouds.
Their chief effect is to affect the seeing of units on the other
side of the clouds.
Wind affects the weather by causing clouds and storms to move around.
Certain unit types, such as sailing ships and balloons,
may depend on the wind to move around.
Games may assert that the playing area represents part of a sphere,
possibly tilted on its axis,
and that poles and equator correspond to various latitudes,
which has the effect of producing seasons.
The game specifies the temperature extremes for poles and equator,
for both midsummer and midwinter, then the weather phase interpolates
to get the average temperature for the current turn and at each latitude
in the world.
@node Economy Backdrop, Randomness Backdrop, Climate Backdrop, Playing Xconq
@section Economy
The economy in @i{Xconq} is based upon materials.
Games that do not include any material types do not
have any of the activities described in this section.
@subsection Consumption
Units consume their supplies, both in the course of existence,
and by motion/combat.
The rate depends on game and unit type; it consists of an overhead
consumed each turn without fail, and consumption for each cell of movement.
The total is a max, not a sum, since units with a constant consumption
rate are not likely to need additional supplies to move (consider foot
soldiers who eat as much sitting around as they do walking).
Supplies may also be consumed for production and repair, again depending
on game and unit types, but this consumption happens during the build phase.
Consumption is not affected by the situation of the consuming unit;
armies in troop transports eat just as much as when in the field.
@subsection Movement of Materials
Excess production is discarded, unless it can be unloaded into the
producer's occupying units, or distributed to nearby units via
@dfn{supply lines}.  Supply lines automatically exist between units
that are close enough (as set by the game), and there is no
need for explicit manipulation.
Supply line length depends on the game and the units on both ends,
but is not affected by the intervening terrain.
Supply redistribution is managed by logistics experts, who are ignorant
of the war effort and seek only to even everything out.
The redistribution method is rather adhoc; units try to get rid of all
their excess supply, and try to take up supply from other units within
supply range.  Each direction is controlled independently, so for instance
airplanes can get automatically refueled from a nearby city, but not from
each other.  No unit will transfer all of its supply via supply lines.
Normally units in the same cell can exchange supplies, but some games
can disable this behavior, so that explicit transfer using the give and
take commands is always necessary.
@node Randomness Backdrop, Scoring, Economy Backdrop, Playing Xconq
@section Random Events
Some games may include @dfn{random events}.
These are usually rare, but not always -- be sure you know the odds!
@subsection Accidents
For some types of units in some types of terrain,
there is a chance for an accident to wreck or eliminate the unit instantly.
This depends on both unit type and terrain type.
If the accident occurs, the unit is wrecked or vanishes
along with all its occupants.
``Wrecking'' and ``vanishing'' have separate probabilities.
Occupants may survive wrecking, but never vanishing.
@subsection Attrition
Attrition is ``slow death'';
it takes away some number of hit points each time it occurs.
The rate of attrition depends on unit type and terrain or transport type.
Very low attrition rates may only take away one hp once in a while.
@subsection Revolt
In a revolt, a unit
changes sides spontaneously, perhaps to independence, perhaps to the side
of a nearby unit.
Occupants will either change over or be killed.
Any plans will be cancelled.
@subsection Surrender
Surrender only occurs if a unit is
capable of attack or capture is close enough to attempt it.
The capturing unit does not move.
Occupants of the surrendering unit also change over or die.
@c Chance of surrender is increased by low unit morale [define].
@node Scoring, , Randomness Backdrop, Playing Xconq
@section Scoring
@quotation
Victory at all costs, victory in spite of all terror,
victory however long and hard the road may be;
for without victory there is no survival.
-- WINSTON CHURCHILL (1940)
@end quotation
Different games can have different ways for players to win or lose.
Some games may not have any scoring at all.
You should be aware of the scoring rules
@emph{before} you start to play the game!
In @i{Xconq}, scoring is implemented by a game design's @dfn{scorekeepers}.
Each scorekeeper tests some sort of condition and/or maintains
a numeric score.
Scorekeepers also define when they run
(perhaps only during certain turns or certain times within a turn)
and which sides to look at.
Each scorekeeper is independent of the others,
meaning it only takes one to decide if you win or lose.
In a game with many players, winning and losing can be
a complicated issue; read the conditions carefully.
A scorekeeper can also decide to declare a game to be a draw and
end it on the spot.
Once a side has won, it is out of the game.
Some scorekeepers only allow one winner, others allow several;
in those cases, the scorekeeper will say what happens to the winning
side's units.
Once a side has lost, it cannot be brought back into a game, even if
another side tries to give it some more units or otherwise to reverse
things.
It may also be possible to declare a draw, but all players in a game
have to agree to this.  While human players just have to enter the
appropriate command (or answer appropriately when asking to quit the
game), AIs may not always be willing to go along,
particularly if they think they still have a chance to win.
If that happens, you must continue fighting.
(Some cowards have been known to abort the program or reboot the machine;
unfortunately @i{Xconq} cannot prevent such slimy tricks.)
Finally, some games may record everybody's final scores into a file.
@subsection ``Last Side Wins''
The most common form of scoring in @i{Xconq} is called
@code{last-side-wins}.  It is basically a fight to the death;
any side that loses all of its units loses, and the last side
with any units remaining is declared the winner.
It is possible that more than one side will lose all of its units
at the same time, in which case the game is declared a draw.
Since this would sometimes lead to bizarre stalemates (a submarine
could hide at sea, thus preventing the side from losing, for instance),
many games also define a @dfn{point value} for units.
In such cases, @code{last-side-wins} makes a side lose when the sum
of point values of all its units is zero,
and the interface will have some way to display your current points.
[following sections should help player interpret scorekeeper displays]
@subsection Occupation
Occupation means that you have one of your own units
in or near a fixed location or unit.
@subsection Unit Counts/Sums
This is a simple count of units, or else a summation of the values
of some property, such as hit points.
@section Advanced Play
This section covers additional features that may interest
experienced players.
@subsection Mixing Game Modules
Some interfaces (such as those using Unix-style command lines) may let you
ask for more than one game design when starting up.
This is sometimes useful, for instance, if you want to play on
the @code{steppes} world with a non-standard set of units;
your command line might look like @code{-g my-hacked-standard -g steppes}.
You can also turn things around and load a file with your own changes
after a complete game, as in {-g gettysburg -g my-tweaks}.
Be aware, however, that this cannot be guaranteed to work always,
since the mixed-together game designs may have
mutually conflicting definitions, or interfere with
each other in subtle or not-so-subtle ways.  Just imagine the disaster
if the world consists entirely of terrain that is instant death to your
initial units!  Worse, @i{Xconq} may start up and run OK for awhile,
then at the moment you're about to win---the object that you must capture
simply cannot be captured by any unit at all.
So be careful about mixing designs!
@subsection Personalizing Your Side
Many games will pre-assign your side's name, emblem, enemies, and
so forth.  However, many others allow you to change all that to suit
your tastes.
The name is a proper noun such as ``Poland'',
the noun is what you would call an individual,
such as ``Pole'', the plural is for more than one,
and <adj> is the adjective for things on that side, such as ``Polish''.
The color scheme is a comma-separated list of color names,
and <image name> names some sort of image file (like a bitmap).
The image may be of any size and combination of colors, with the caveat
that it may not always work correctly.  For instance, two subtly different
shades may get fused into a single solid color.  The emblem should also be
small enough to fit reasonably into unit icons.
As a rule, most national flags will fit into a 7x5 rectangle,
and coats of arms into a 7x9 region.
The color scheme should be useful by itself,
when the unit icons are too small to fit the emblem.
@i{Xconq} will not allow you to have the same name, color, or emblem as
another player in the same game.
The interface-specific side configuration uses the favored mechanism
for that interface (if one is defined).
You should check with the interface documentation for more details.
@section Playing Hints
This section is a collection of bits of information and advice derived
from players' actual experience playing @i{Xconq}.
@subsection Alliances
Informal alliances frequently happen in games involving more than two people,
so I have a few words of advice.  First, an alliance between two of the
players is almost certain in a three-person game, and inevitably
results in the ``odd man out'' being quickly defeated.  In four-person
games, the alliances could be decided after looking at the map via
a command-line option such as @code{-v},
so that one pair is not hopelessly separated.  Five or more players is
going to be a free-for-all of formal and informal alliances.
Some scenarios are designed with a particular number of players in mind.
@subsection Advantage
When you set the advantage, @i{Xconq} multiplies the desired advantage
with the normal number of starting units, then divides by the default
advantage and ROUNDS DOWN.  This means that you might end up with a lot
fewer units than you thought.  For instance, suppose that you have a
game where each player starts with one large city and five towns, and
this is considered to be an advantage of 10, because one large city is
worth about as much as 5 towns.  Then if you select an
advantage of 8, and your opponent selects 14 (because you're a better
player perhaps), @i{Xconq} will give you 8/10 of the normal setup,
which means four towns and NO large city.  Your opponent will get
14/10 of the setup, which works out to one large city and seven towns,
which is really a 1 to 3 disparity, much more than the planned 4 to 7.
@section Cheating
There is none.  The standard builtin AI @code{mplayer} does not cheat;
it always plays according to the same rules as you do.
This should be true of any AI that has been added to @i{Xconq}.
If you have evidence that would seem to indicate that any AI is using
information it should not have, or is otherwise cheating,
that is a bug and should be reported.
@section Technical Details
The coordinate system is ``oblique'',
with the X-axis in the usual horizontal,
and the Y-axis vertical, but tilted to the right at a 60-degree angle.
@example
      Y
  \  /
   \/
---------X
  / \
 /   \
@end example
The additional left-leaning axis is the x = - y line.